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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document is part 5 of a multi-part TS covering the 3 rd Generation Partnership Project: Technical 
Specification Group Services and System Aspects; Telecommunication Management; Configuration Management, as 
identified below: 

Part 1: "3G Configuration Management: Concept and Requirements"; 

Part 2: "Notification Integration Reference Point: Information Service Version 1"; 

Part 3: "Notification Integration Reference Point: CORBA Solution Set Version 1:1"; 

Part 4: "Notification Integration Reference Point: CMIP Solution Set Version 1:1"; 

Part 5: "Basic Configuration Management IRP: Information Model Version 1"; 

Part 6: "Basic Configuration Management IRP CORBA Solution Set Version 1:1"; 

Part 7: "Basic Configuration Management IRP CMIP Solution Set Version 1:1"; 

Part 8: "Name Convention for Managed Objects". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G-network as it evolves. CM actions have the objective to control and monitor the actual 
configuration on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator 
or functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service. The CM actions are 
initiated either as a single action on a NE of the 3G-network or as part of a complex procedure involving actions on 
many NEs. 

The interface Itf-N, defined in 3GPP TS 32.102 [2], for CM is built up by a number of Integration Reference Points 
(IRPs) and a related Name Convention, which realise the functional capabilities over this interface. The basic structure 
of the IRPs is defined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. For CM, a number of IRPs (and the Name 
Convention) are defined herein, used by this as well as other Technical Specifications for Telecom Management 
produced by 3GPP. All these are included in Parts 2 and onwards in the 3GPP TS 32.106. 

The present document is Part 5 of 32.106 - "Basic Configuration Management IRP: Information Model Version 1". 
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Scope 



The present document (Basic Configuration Management (CM) IRP: Information Model) defines an Integration 
Reference Point (IRP) through which an IRP Agent' (typically an Element Manager or Network Element) can 
communicate basic Configuration Management related information to one or several IRPManagers' (typically Network 
Managers). This version of the IRP is mainly intended for "passive management" of high-level network configuration 
and status information as required by a Network Manager. 

The present document is divided in three main parts: 

1 . specifies a generic IRP Information Service with operations and notifications to be used by an 'IRPManager' 
to retrieve information on managed objects maintained by an 'IRP Agent'. 

2. specifies a generic Network Resource Model, NRM (also referred to as a Management Information Model - 
MIM) with definitions of Managed Object Classes. 

3. defines the UMTS management NRM by reusing this generic model either by direct reuse or sub-classing. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs. In addition to the subject IRP, it is expected that IRPs will be defined for functional areas like 
Security management, Software management, Network & Service provisioning, etc. An important aspect of such a split 
is that the Network Resource Models (NRMs) defined in different IRPs are consistent. The Basic CM IRP here provides 
a base for all CM-related resource modelling. 

To summarize, the Basic CM IRP has three main purposes: 

(1) to define an interface for retrieval of Configuration Management information, 

(2) to define a generic Network Resource Model that constitutes a base from which other (more specialized) 
resource models can inherit, and 

(3) to define the applied UMTS management Network Resource Model. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.106-1 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently (in Release 99) however, all (non-containment) associations are modelled by means 
of reference attributes of the participating MOs. 

Managed Element (ME): An instance of the Managed Object Class G3ManagedElement. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the objects 
that belong to the class (the term "attribute" is taken from TMN and corresponds to a "property" according to CIM). 
Furthermore, an MO class can have operations that represent the behaviour relevant for that class (the term "operation" 
is taken from TMN and corresponds to a "method" according to CIM). An MO class may support notifications that 
provide information about an event occurrence within a network resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 
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(3) 



a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 1 depicts the relationships between 
a Name space and a number of participating MOs (the shown association is of a non-containment type) 




Namespace (containment hierarchy) 
O O MO V MIB 



O 



Association 



J 

Figure 1 : Relationships between a Name space and a number of participating MOs 
Management Information Model (MEM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.106-8 [13]) restricts 
the name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the Iub interface towards the RNC. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AUC Authentication Centre 

BG Border Gateway 

CIM Common Information Model 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DMTF Distributed Management Task Force 

DN Distinguished Name (see 3GPP TS 32.106-8 [13]) 

EIR Equipment Identity Register 

EM Element Manager 

FM Fault Management 

GDMO Guidelines for the Definition of Managed Objects 

GGSN Gateway GPRS Support Node 

GMSC Gateway MSC 

GPRS General Packet Radio System 

HLR Home Location Register 

IDL Interface Definition Language 

IEC International Electro-technical Commission 

IETF Internet Engineering Task Force 

IRP Integration Reference Point 

ISO/IEC International Standards Organization 

ITU-T International Telecommunication Union, Telecommunication Sector 
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Iub Interface between RNC and Node B 

LDAP Lightweight Directory Access Protocol 

NM Network Manager 

NE Network Element 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MIT Management Information Tree (or Naming Tree) 

MO Managed Object 

MOC Managed Object Class 

MOF Managed Object Format 

MOI Managed Object Instance 

MSC Mobile Services Switching Centre 

NE Network Element 

NR Network Resource 

NRM Network Resource Model 

OSI Open Systems Interconnection 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.106-8 [13]) 

RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

SMI Structure of Management Information 

SMS Short Message Service 

SMS-GMSC SMS Gateway MSC 

SMS-IWMSC SMS Interworking MSC 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

VLR Visitor Location Register 

WBEM Web-Based Enterprise Management 

XML extensible Mark-up Language 



4 System overview 

4.1 System context 

Figure 2 and Figure 3 identify system contexts of the subject IRP in terms of its implementation called IRP Agent and 
the user of the IRP Agent, called IRPManager. For a definition of IRPManager and IRP Agent, see 3GPP TS 32.102 [2]. 

The IRP Agent implements and supports the Basic CM IRP. The IRP Agent can be an Element Manager (EM) or a 
mediator that interfaces one or more NEs (see Figure 2), or it can be a Network Element (NE) (see Figure 3). In the 
former case, the interfaces (represented by a thick dotted line) between the EM and the NEs are not subject of this IRP. 

An IRPManager using this IRP shall choose one of the two System Contexts defined here, for each NE. For instance, if 
an EM is responsible for managing a number of NEs, the NM shall access this IRP through the EM and not directly to 
those NEs. For another IRP though, the System Context may be different. 
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Figure 2: System Context A 
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Figure 3: System Context B 
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4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2], 

The following defines the meaning of Mandatory and Optional MOC attributes and associations between MOCs, in 
Solution Sets to the Basic CM IRP: 

• The IRPManager shall support all mandatory attributes/associations. The IRPManager shall be prepared to 
receive information related to mandatory as well as optional attributes/associations without failure; however 
the IRPManager does not have to support handling of the optional attributes/associations. 

• The IRPAgent shall support all mandatory attributes/associations. It may support optional 
attributes/associations. 

An IRPAgent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

• rules for vendor-specific extensions remain to be fully specified, and 

• many scenarios under which IRPManager and IRPAgent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor-specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 
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Modelling approach 



This clause identifies the modelling approach adopted and used in this IRP. 
As previously described, the IRP is structured in: 

(1) an IRP Information Model (the subject document) that specifies the interface in a protocol neutral manner, and 

(2) a number of IRP Solution Sets that provide the actual realization of the operations and notifications defined in 
the IRP Information Model for each protocol environment. 

Figure 4 shows the structure of the Basic CM IRP (including a number of possible Solution Sets). 



Basic Configuration Management IRP: Information model 



IRP Information Service - operations and notifications visible over the IRP. 
Network Resource Model (NRM) with MO classes (in UML) 




SNMP 

Solutio 

nSet 



LDAP 

Solutio 
n Set 



WBEM 
Solutio 
n Set 



CORBA 

Solutio 
nSet 



CMIP 

Solutio 

nSet 



Protocol 
independent 



Protocol 
specific 



Figure 4: Basic CM IRP Structure with example Solution Sets 

As shown in Figure 4, the IRP Information Model consists of two main parts: 

1. The IRP Information Service 

This is a specification of the operations and notifications that are visible over the IRP. These operations are generic 
in the sense that they do not specify the Managed Objects that are retrieved/manipulated over the interface. 

2. The Network Resource Model (NRM) 

This is a protocol-independent model that specifies a number of Managed Object classes (with attributes, 
operations and associations), which are relevant in the context of the subject IRP. Each Solution Set shall provide 
an implementation of this resource model with: 

a) references to standard models that are applicable for the corresponding protocol environment, and 

b) extensions to these standard models for the parts of the NRM that are not covered. 

The modelling approaches for these two aspects of the IRP are somewhat different and are described separately in the 
next two subclauses. 

5.1 IRP Information Service modelling approach 

The IRP Information Service of the subject IRP specifies a number of protocol-independent operations and notifications 
that are needed by an IRPManager to retrieve CM information from an IRP Agent. 
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The operations and notifications of the IRP Information Service are mainly based on the principles of the Common 
Management Information Service (CMIS) defined in ITU-T X.710 [7] and ITU-T X.721 [8] (M-GET etc.). Note 
however, that the Information Service of the subject IRP is focused on the operations and notifications needed for basic 
CM purposes and thus only covers a subset of the operations/notifications defined in ITU-T X.710 [7]/ITU-T X.721 [8]. 

It is expected that most Solution Sets will implement the operations and notifications by mapping them to standard 
operations (and possibly standard notifications) that are applicable in the corresponding protocol environment. 
The CMIP Solution Set should for instance map the operations to the more generic operations defined in CMIS, an 
SNMP Solution Set should map the operations to applicable SNMP operations, and the CORBA Solution Set should 
map the operations to applicable OMG/CORBA services. 

5.2 Network Resource Modelling approach 

The NRM defined in the subject IRP bases its design mainly on work captured in ITU-T M.3100 [4], [5], [6]. However, 
as described in the Scope of the present document (clause 1): The model is highly simplified for the purpose of the NM, 
based on the assumption that all of the detailed CM actions, including fault correction after one or more alarms, are 
performed by an Element Manager which knows the vendor-specific NRM and configuration, and which is launched by 
the NM when necessary. 

Moreover, the classes defined herein are very basic, only for the necessary support of Fault Management (FM) and 
Performance Management (PM), which means that they contain very few attributes - basically only for naming. 

In addition, also some basic associations between some of the classes are defined. 

The NRM is split into a generic and an UMTS-specific part. 

Detailed mapping to the actual standard model is described in each Solution Set. It is important to note that if one 
selects a specific management protocol, one should also as base use existing de-facto conventions and standard resource 
models that are applicable to that protocol environment. Examples: 

• SNMP Solution Sets (SMI-specifications) should be consistent with existing standard SNMP MIB-modules in 
order to function in an SNMP environment. 

• CMIP Solution Sets (GDMO-specifications) should be based on standard models like ITU-T X.721 [8] and ITU- 
T M.3100 [4], [5], [6] in order to function in an OSI/TMN environment. 

• WBEM Solution Sets (MOF/XML-specifications) should be based on CIM to function in a WBEM 
environment. 

NOTE: CORBA Solution Sets are special in the sense that no such corresponding de-facto standard models exist, 
and CORBA/IDL is transparent to any model. Thus, one has full freedom to choose the same model for 
the CORBA Solution Set to this IRP, as the IRP Information Model defined herein. 

Finally, all solution sets shall of course be consistent with the IRP Information Model defined herein. 



6 IRP Information Model 

6.1 Introduction 

As already introduced in the previous clause, the present clause defines the Basic CM IRP Information Model in the 
form of the IRP Information Service and the Network Resource Model (split into a generic and an UMTS-specific part). 

The corresponding Solution Set specifications provide protocol dependent object models. They provide the actual 
realization of the operations and notifications defined in this subclause in each protocol environment. One may find that 
the operation names and operation parameters defined in the protocol-neutral model differ from those defined in the 
Solution Sets (e.g. due to mappings to existing standard models that are applicable for a specific Solution Set). 
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6.2 



IRP Information Service 



This subclause specifies the operations and notifications that are visible over this IRP. These operations are generic in 
the sense that they do not specify the MOs that are retrieved/manipulated over the interface. 



6.2.1 



Interfaces 



Figure 5 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager, described using UML notation (Interface in IRP Information Model is identical to concepts conveyed by 
stereotype «interface» of UML). Parameters and return status are not indicated. 

Two interfaces are defined. One is called BasicCmlRPOperations. This interface defines operations implemented 
by IRPAgent and used (or called) by IRPManager. The other is called BasicCmlRPNotif ications. This interface 
defines notifications implemented by IRPManager and used by IRPAgent. 



IRPManage 



«lnterface» 
BasicCmlRPOperation 



%3etM0Attribut.es () 
%3etContainment() 
*getBasicCmlRPVersion() 






«lnterface» 
BasicCmlRPNotification 



VotifyObjectCreation() 
VotifyObjectDeletion() 
■%notify Attribute ValueChangeQ 



IRPAgent 



6.2.2 Operations 



Figure 5: UML Interface Class Diagram 



6.2.2.1 



Operation getMoAttributes (M) 



This operation is invoked by IRPManager to request the retrieval of management information (Managed Object 

attribute names and values) from the MIB maintained by IRPAgent. One or several Managed Objects may be retrieved - 

based on the containment hierarchy. The operation corresponds to the M-GET service defined by CMIS (ITU-T X.710 

[7]). 

A Solution Set may choose to split this operation in several operations (e.g. operations to get "handlers" or "iterators" to 

Managed Objects fulfilling the scope/filter criteria and other operations to retrieve attribute names/values from these 

"handlers"). 
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Table 1 : Parameters of getMoAttributes 



Name 


Qualifier 


Description 


baseObject Instance 


Input, M 


The MO where the search starts. This is a full Distinguished Name according to 
3GPPTS 32.106-8 [13]. 


scope 


Input, M 


This parameter defines how many levels of the containment hierarchy to search 
(i.e. apply the filter defined below). The search starts from the MO given by the 
baseOb jectinstance parameter. The levels of search that may be performed 
are: 

• the base object alone (default); 

• the n-th level subordinates of the base object; 

• the base object and all of its subordinates down to and including the n-th 
level; 

• the base object and all of its subordinates. 


filter 


Input, M 


This parameter defines a filter test to be applied to the scoped Managed 
Object(s). If the filter is empty, all of the managed objects included by the scope 
are selected. 

The actual syntax and capabilities of the filter is Solution Set specific. However, 
each Solution Set should support a filter consisting of one or several assertions 
that may be grouped using the logical operators AND, OR and NOT. Each 
assertion is a logical expression of attribute existence, attribute value comparison 
("equal to X, less than Y" etc.) and MO Class. 


attributeList In 


Input, M 


This parameter identifies the attributes to be returned by this operation. In R99, 
only the semantics "Return all attributes" shall be supported. An empty list means 
"Return all attributes". For future releases the possibility to specify a list of 
attributes is expected. 


managedObje etc lass 


Output, M 


For each returned MO: The class of the MO. 


managedOb jectlnstan 
ce 


Output, M 


For each returned MO: The name of the MO. This is a full Distinguished Name 
according to 3GPP TS 32.106-8 [13]. 


attributeList Out 


Output, M 


For each returned MO: A list of name/value pairs for the MO attributes. 


status 


Output, M 


(a) Operation succeeded, or 

(b) Operation failed because of specified or unspecified reason. 



6.2.2.2 Operation getContainment (O) 

This (optional) operation is only intended for retrieval of the containment relations from the MIB. 

The output parameter 'containment' of the operation shall contain a list of all Managed Object instances in the MIB 
maintained by IRP Agent (or a subset starting from a given base object) including containment information (naming 
tree). 

The structure and format of the output parameter 'containment' are Solution Set dependent. 

Table 2: Parameters of getContainment 



Name 


Qualifier 


Description 


baseObject 
Instance 


Input, M 


The MO where the search starts. This is a full Distinguished Name according to 
3GPPTS 32.106-8 [13]. 


scope 


Input, O 


This parameter gives a value N defining how many levels of the containment 
hierarchy from the baseObjectlnstance to include in the result. 
The levels of inclusion that may be performed are: 

• the base object alone (default); 

• the n-th level subordinates of the base object; 

• the base object and all of its subordinates down to and including the n-th level; 

• the base object and all of its subordinates. 


containment 


Output, M 


A list of DN of all Managed Object instances that satisfy the scope. 


status 


Output, M 


(a) Operation succeeded, or 

(b) Operation failed because of specified or unspecified reason. 
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6.2.2.3 



Operation getBasicCmlRPVersion (M) 



IRPManager wishes to find out the Basic CM IRP SS version(s) supported by IRP Agent. IRP Agent shall respond with 
a list of supported Basic CM IRP SS versions. Since the present document defines the first IRP version, 
implementation of IRP Agent in compliance to this version shall return with one version number in the list. 

Table 3: Parameters of getBasicCmlRPVersion 



Name 


Qualifier 


Description 


versionNumberList 


Output, M 


It indicates one or more SS version numbers supported by the IRPAgent. 
This shall in Release 99 contain only one version number. 


status 


Output, M 


(a) Operation succeeded in that versionNumberList contains valid result. 

(b) Operation failed. Output parameter versionNumberList may contain invalid 
result. 



6.2.3 Notifications 



6.2.3.1 



General 



Operations that IRPManager uses to manage subscription to receive notifications are specified in Notification IRP IS 
3GPP TS 32.106-2 [3], which also specifies a generic notification notify. Notification IRP IS (3GPP TS 32.106-2 
[3]) defines a number of parameter-attributes that are commonly carried in notifications as well. 

The commonly carried parameter-attributes are collectively called notif icationHeader in the present document. 
The parameter-attribute names and their qualifiers are listed in Table 4. 

Table 4: Notification Header 



Parameter-Attributes defined in 3GPP TS 32.106-2 [3] 


Qualifier for use in this IS 


managedObje etc lass 


M 


managedOb ject Instance 


M 


notification Id 


O 


eventTime 


M 


systemDN 


C 


eventType 


M 


extendedE vent Type 


M 



The following subclauses define specific notifications relevant for Basic CM IRP by extending notify in Notification 
IRP IS (3GPP TS 32.106-2 [3]). 



6.2.3.2 



Notification notifyObjectCreation (O) 



IRPAgent notifies the subscribed IRPManager that a new Managed Object has been created and that the new object 
satisfies the filter constraint expressed in IRPManager's subscribe operation (see 3GPP TS 32.106-2 [3]). This 
notification is based on the ob jectCreation notification type specified in ITU-T X.721 [8] and ITU-T X.730 [9] 
(difference compared to these specifications are indicated in the description below). 

When a notifyObjectCreation notification is received, that in the MOI Parameter-Attribute includes superior 
(parent) MO(s) that the IRPmanager is not aware of (in case the object creation notifications for that or those objects 
have not been received yet, or are lost), these superior MO(s) shall also be assumed to be created. 
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Table 5: Parameters for notifyOb jectcreation 



Name 


Qualifier 


Description 


notificationHeader 


Input, M 


See Table 4: Notification Header. 


cor relatedNotif icat ions 


Input, O 


A set of notifications that are correlated to the subject notification. 
Defined in ITU-T X.733 [10]. 


additionalText 


Input, O 


It can contain further information on the creation of the MO. 


source Indicator 


Input, O 


This parameter, when present, indicates the source of the operation that 
led to the generation of this notification. It can have one of the following 
values: 

• resource operation: The notification was generated in response to 
an internal operation of the resource; 

• management operation: The notification was generated in response 
to a management operation applied across the managed object 
boundary external to the managed object; 

• unknown: It is not possible to determine the source of the operation. 


attributeList 


Input, O 


The attributes (name/value pairs) of the created MO. 



6.2.3.3 



Notification notifyObjectDeletion (O) 



IRP Agent notifies the subscribed IRPManager of a deleted Managed Object. The IRP Agent invokes this notification 
because the subject notification satisfies the filter constraint expressed in the IRPManager subscribe operation (see 
3GPP TS 32.106-2 [3]). This notification is based on the ob jectDeletion notification type specified in ITU-T 
X.721 [8] and ITU-T X.730 [9] (difference compared to these specifications are indicated in the description below). 

When a Managed Object is notified as deleted, all subordinate Managed Objects (i.e. the complete sub-tree of contained 
MOs under the deleted MO), if any exist, shall also be assumed to be deleted. When an IRP Agent is able to detect an 
atomic operation leading to the removal of a whole sub-tree of the MIB, it shall send a delete notification for only the 
top MO of the deleted sub-tree. Furthermore, all associations to a deleted Managed Object shall be deleted by the 
IRPAgent. 

Table 6: Parameters for notifyObjectDeletion 



Name 


Qualifier 


Description 


notificationHeader 


Input, M 


See Table 4: Notification Header. 


cor relatedNotif icat ions 


Input, O 


A set of notifications that are correlated to the subject notification. 
Defined in ITU-T X.733 [10]. 


additionalText 


Input, O 


It can contain further information on the deleted MO. 


source Indicator 


Input, O 


This parameter, when present, indicates the source of the operation that 
led to the generation of this notification type. It can have one of the 
following values: 

• resource operation: The notification was generated in response to 
an internal operation of the resource; 

• management operation: The notification was generated in response 
to a management operation applied across the managed object 
boundary external to the managed object; 

• unknown: It is not possible to determine the source of the operation. 


attributeList 


Input, O 


The attributes (name/value pairs) of the deleted MO. 



6.2.3.4 



Notification notifyAttributeValueChange (O) 



IRPAgent notifies the subscribed IRPManager of a change of one or several attributes of a Managed Object in the 
NRM. The IRPAgent invokes this notification because the subject notification satisfies the filter constraint expressed in 
the IRPManager subscribe operation (see 3GPP TS 32.106-2 [3]). This notification is based on the 
attributeValueChange notification type specified in ITU-T X.721 [8] and ITU-T X.730 [9] (difference 
compared to these specifications are indicated in table 7). 
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Table 7: Parameters for notifyAttributeValueChange 



Name 


Qualifier 


Description 


notificationHeader 


Input, M 


See Table 4: Notification Header. 


cor relatedNotif icat ions 


Input, O 


A set of notifications that are correlated to the subject notification. 
Defined in ITU-T X.733 [10]. 


additionalText 


Input, O 


It can contain further information on the attribute change of the MO. 


source Indicator 


Input, O 


This parameter, when present, indicates the source of the operation that 
led to the generation of this notification type. It can have one of the 
following values: 

• resource operation: The notification was generated in response to 
an internal operation of the resource; 

• management operation: The notification was generated in response 
to a management operation applied across the managed object 
boundary external to the managed object; 

• unknown: It is not possible to determine the source of the operation. 


attributeValueChange 
Definition 


Input, M 


The changed attributes (name/value pairs) of the MO (with both new 
and, optionally, old values). 



6.3 Generic Network Resource Model (NRM) 

This subclause defines the generic managed object classes supporting the Basic CM IRP. These object classes are 
protocol environment neutral and the model does not define the syntax or encoding of the operations and parameters. 

The model described in this subclause allows for Managed Elements to be defined for management purposes according 
to the functionality contained within them. As an example, a single implementation of a combined MSC and VLR may 
be required. However, in the implementation it is required to create a single interface for the management of this 
element. This is expected to be achieved by instantiating a G3ManagedElement MOC that contains the 
"mscFunction" MOC, the "vlrFunction" MOC (as in the GSM 12.xx-series of specifications), and other generic or non- 
UMTS specific MOCs as appropriate to define the manageable capability of that managed element. See also the 
managedElementType attribute in the G3ManagedElement MOC definition. 

It should be noted that, although this model allows for combined managed element functionality as described above, in 
this subclause only the high-level and generic MOCs are defined. UMTS MOCs modelling more specific managed 
element functionality are defined in subclause 6.4. 

6.3.1 Managed Object Class (MOC) diagrams 

6.3.1.1 Inheritance hierarchy- 

Figure 6 shows the inheritance hierarchy for the generic MO classes defined in this IRP. 
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G3SubNetwork 



MeContext 



ManagementNode 



G3ManagedElement 



IRPAgent 

(from Interface Service) 



ManagedFunction 



NotificationIRP 



AlarmIRP 



BasicCmIRP 



Figure 6: Generic NRM Inheritance Hierarchy 
6.3.1 .2 Containment/Naming and Association diagram 

Figure 7 shows the containment/naming hierarchy and the associations of the generic MO classes defined by this IRP. 

NOTE: The Managed Object containment/naming relationships are in the diagram(s) below indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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+ Manages 

0..* {R99: 0..1 



ManagementNode 



0..* 
{R99: 0..1 } 







MgmtAssociation 



IRPAgent 

(from Interface Service) n * rp)qq- n -n 



-o 



G3ManagedElement +ManagedBy 




0..* 



NotificationIRP 



{R99: 0..1} 
BasicCmIRP 



NOTE 1: G3ManagedElement may be contained in either a G3SubNetwork or an MeContext instance, or have no parent 

instance at all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 

Figure 7: Generic NRM Containment/Naming and Association diagram 

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.106-8 [13] that 
expresses its containment hierarchy. As an example, the DN of a Managed Element instance could have a format like: 

g3SubNetwork=Sweden,meContext=MEC-Gbg-l, g3ManagedElement=RNC-Gbg-l . 



6.3.2 Managed Object Class (MOC) definitions 

A general note regarding all the notification tables defined for each MOC below: Each MOC may potentially send the 
notifications listed in the notification table for the MOC. The notifications with qualifier (M) shall be supported by the 
MOC, and the notifications with qualifier (O) may be supported by the MOC. 

For example, if Notification notifyObjectCreation defined in Basic CM IRP has the qualifier (M), then if a MOC is 
defined such that it emits such a notification, this notification shall be emitted when appropriate (i.e. when a new object 
is created). If Notification notifyChangedAlarm has the qualifier (O) in Alarm IRP (see 3GPP TS 32.111-2 [11]), then if 
a MOC is defined such that it emits such a notification, this notification may or may not be emitted when appropriate. 
Further, if a notification in the qualifier column (of the MOC notification tables) has a reference to another 
specification, it means that the qualifier for the notification is specified in the referred specification. 
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6.3.2.1 MOC G3SubNetwork 

This Managed Object Class represents a set of managed entities as seen over the Itf-N. 

A G3SubNetwork may have 0...N instances. It shall be present if either a ManagementNode or multiple 
G3ManagedElements are present (i.e. ManagementNode and multiple G3ManagedElement instances shall have 
G3SubNetwork as parent). Restriction in R99: N=l. 

Table 8: Attributes of G3SubNetwork 



Name 


Qualifier 


Description 


g3SubNetworkId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when 
naming an instance of the G3SubNetwork object class. This 
RDN uniquely identifies the object instance within the scope of 
its containing (parent) object instance. 


dnPref ix 


READ- ONLY, C 


It carries the DN Prefix information as defined in Annex C of 
32.106-8 [13]. It shall only be specified if the instance of 
G3SubNetwork is a local root instance of the MIB. Otherwise the 
value shall carry the NULL semantics. 


userLabel 


READ- ONLY, M 


A user-friendly (and user assigned) name of the associated 
object. 



Table 9: Notifications of G3SubNetwork 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.3.2.2 



MOC G3ManagedElement 



This Managed Object Class represents telecommunications equipment or TMN entities within the telecommunications 
network that performs Managed Element (ME) functions, i.e. provides support and/or service to the subscriber. 
An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being 
monitored and/or controlled. MEs may or may not additionally perform element management functionality. 
An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a 
"Network Element". This class is similar to the Managed Element class specified in ITU-T M.3100 [4], [5], [6]. 

A G3ManagedElement may be contained in either a G3SubNetwork or in an MeContext instance. A single 
G3ManagedElement seen over the Itf-N may also exist stand-alone with no parent at all. 

As mentioned in the introduction to subclause 6.3 (the generic model), the G3ManagedElement MOC may be used to 
represent combined ME functionality (as indicated by the managedElementType attribute and the contained instances of 
different functional MOCs). 

Single function G3ManagedElement managed object instances will have a 1..1 containment relationship to a function 
Managed Object (in this context a function MO is an MO derived from the ManagedFunction MOC). Multiple function 
G3ManagedElement managed object instances will have a 1..N containment relationship to function Managed Objects. 

It should be noted that although the present document only models UMTS specific functionality with some UTRAN 
related MOCs, the G3ManagedElement MOC may still be used to represent other ME types than RNC or NodeB, e.g. 
an MSC or a combined MSC/HLR/VLR. 
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Table 10: Attributes of G3Managed Element 



Name 


Qualifier 


Description 


g3ManagedElementId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of the G3ManagedElement object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance. 


dnPref ix 


READ- ONLY, C 


It carries the DN Prefix information as defined in Annex C of 32.106-8 
[13]. It shall only be specified if the instance of G3ManagedElement is a 
local root instance of the MIB. Otherwise the value shall carry the NULL 
semantics. 


managedElementType 


READ-ONLY, M 


The type of managed element. It is a multi-valued attribute with one or 

more elements. Thus, it may represent one ME functionality, e.g. an 

RNC, or a combination of more than one functionality e.g. an 

MSC/HLR. The allowed members of this attribute are: 

RNC, NodeB, MSC, HLR, VLR, AUC, EIR, SMS-IWMSC, SMS-GMSC, 

GMSC, SGSN, GGSN and BG. 

The actual syntax and encoding of this attribute is Solution Set specific. 


userLabel 


READ-ONLY, M 


A user-friendly name of this object. 


vendorName 


READ-ONLY, M 


The name of the G3ManagedElement vendor. 


userDefinedState 


READ-ONLY, M 


An operator defined state for operator specific usage. (See also Note 
below) 


locationName 


READ-ONLY, M 


The physical location of this entity (e.g. an address). 


managedBy 


READ-ONLY, M 


The value of this attribute shall be the DN of the related 
managementNode instance. This is a reference attribute modelling the 
role (of the association MgmtAssociation) that this ME is managed by 
0-1 managementNode. 


NOTE: In addition to the userDefinedState, state management attributes are expected to be included in the next 
release. 



Table 1 1 : Notifications of G3ManagedElement 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.3.2.3 



MOC MeContext 



This Managed Object Class (MOC) is introduced for naming purposes. It may support creation of unique DNs in 
scenarios when some MEs have the same RDNs due to the fact that they have been manufacturer pre-configured. 
If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same G3SubNetwork 
instance, some measure shall be taken in order to assure the global uniqueness of DNs for all MOIs under those MEs. 
One way could be to set different DnPrefixes for those NEs, but that would require either that: 

a) all LDNs or DNs are locally modified using the new DnPrefix for the upper portion of the DNs, or 

b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. in alarm 
notifications. 

As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have 
to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using 
MeContext as part of the naming tree (and thus the DN) means that the DnPrefix, including a unique MeContext for 
each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to 
new values. 

MeContext have 0..N instances. It may exist even if no G3SubNetwork exists. Every instance of MeContext contains 
exactly one G3ManagedElement during steady-state operations. 
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Table 12: Attributes of MeContext 



Name 


Qualifier 


Description 


meContextld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an instance of 
this object class. This RDN uniquely identifies the object instance within the scope of 
its containing (parent) object instance. 


dnPref ix 


READ- ONLY, C 


It carries the DN Prefix information as defined in Annex C of 3GPP TS 32.106-8 [13]. 
It shall only be specified if the instance of MeContext is a local root instance of the 
MIB. Otherwise the value shall carry the NULL semantics. 



Table 13: Notifications of MeContext 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.3.2.4 



MOC ManagementNode 



This Managed Object Class represents a telecommunications management system (EM) within the TMN that contains 
functionality for managing a number of Managed Elements (MEs). The management system communicates with the 
MEs directly or indirectly over one or more interfaces for the purpose of monitoring and/or controlling these MEs. 

This class has similar characteristics as the G3ManagedElement. The main difference between these two classes is that 
the ManagementNode has a special association to the managed elements that it is responsible for managing. 

Table 14: Attributes Of ManagementNode 



Name 


Qualifier 


Description 


management Node Id 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely 
identifies the object instance within the scope of its containing 
(parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly name of this object. 


vendorName 


READ-ONLY, M 


The name of the ManagementNode vendor. 


userDefinedState 


READ-ONLY, M 


An operator defined state for operator specific usage. 


locationName 


READ-ONLY, M 


The physical location of this entity (e.g. an address). 


manages 


READ-ONLY, M 


The value of this attribute shall be a list of the DN(s) of the related 
ManagedElement instance(s). This is a reference attribute 
modelling the role (of the association MgmtAssociation) that this 
managementNode is responsible for managing 0-N MEs. 



Table 15: Notifications Of ManagementNode 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 










notif yAttributeValueChange 


O 




notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 
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6.3.2.5 



MOC ManagedFunction 



This Managed Object Class is similar to the class gsmManagedFunction defined in GSM 12.20 [12] and is 
provided for sub-classing only. It provides the attributes that are common to functional MO classes. Note that a 
Managed Element may contain several managed functions. The ManagedFunction may be extended in the future if 
more common characteristics to functional objects are identified. 

Table 16: Attributes Of ManagedFunction 



Name 


Qualifier 


Description 


userLabel 


READ-ONLY, M 


A user-friendly name of the associated object. 



6.3.2.6 MOC IRPAgent 

This Managed Object Class represents the functionality of an IRPAgent. It shall be present. For a definition of 
IRPAgent, see 3GPP TS 32.102 [2], 

Restriction in R99: The IRPAgent will be contained under a managed object as follows (only one of the options shall be 
used): 

1. ManagementNode, if the configuration contains a ManagementNode (see Config #1 and Config #2 in Figure A. 1). 

2. G3SubNetwork, if the configuration contains a G3SubNetwork and no ManagementNode (see Config #3 in Figure 
A.1). 

3. G3ManagedElement, if the configuration contains no ManagementNode or G3SubNetwork (see Config #4 in 
Figure A.l). 

Table 17: Attributes of IRPAgent 



Name 


Qualifier 


Description 


irpAgentld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


systemDN 


READ-ONLY, C 


The Distinguished Name (DN) of IRPAgent. Defined in 3GPP TS 32.106-2 [3]. 



Table 18: Notifications of IRPAgent 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yAlarmListRebuilt 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yAt tribute ValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





Note that these notifications are issued based on occurrences on the IRPAgent MOC and not on occurrences on other 
Basic CM IRP managed objects. 

6.3.2.7 MOC Notif icationIRP 

This Managed Object Class represents the Notification IRP capability associated with each IRPAgent. At least one 
instance shall be present for every IRPAgent instance. Restriction in R99: Number of instances = 1 . 
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Table 19: Attributes of Notif icationiRP 



Name 


Qualifier 


Description 


notificationlRPId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Notification IRP version entries. 



6.3.2.8 MOC AlarmIRP 

This Managed Object Class represents the AlarmIRP (see 3GPP TS 32.111-2 [11]) capability associated with each 
IRP Agent. Restriction in R99: Number of instances = 0..1. 

Table 20: Attributes of AlarmIRP 



Name 


Qualifier 


Description 


alarmlRPId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an instance 
of this object class. This RDN uniquely identifies the object instance within the 
scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Alarm IRP (see 3GPP TS 32.111-2 [11]) version entries. 



6.3.2.9 MOCBasicCmIRP 

This Managed Object Class represents the Basic CM IRP capability associated with each IRP Agent. Restriction in R99: 
Number of instances = 0..1. 

Table 21 : Attributes of BasicCmiRP 



Name 


Qualifier 


Description 


basicCmlRPId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Basic CM IRP version entries. 



6.3.3 Associations 



6.3.3.1 



Association MgmtAssociation (M) 



This association is used to represent relationships between one or more MEs and the ManagementNode that is 
responsible for managing the MEs. It has two roles, named Manages and ManagedBy. The role 'Manages' models the 
fact that a ManagementNode is responsible for managing zero or more MEs, and the role ManagedBy models the fact 
that an ME is managed by zero or one ManagementNode. Each role is in the MOC definition mapped to a reference 
attribute with the same name. 

6.4 UMTS Network Resource Model (NRM) 

This NRM includes the generic model defined in subclause 6.3, and in addition it is expected to define MOCs 
modelling the functionality in one or more of the Managed Elements. However, in Release 99 only a more detailed 
model is defined for UTRAN specific functionality. 

These object classes are protocol environment neutral and the model does not define the syntax or encoding of the 
operations and parameters. 
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6.4.1 Managed Object Class (MOC) diagrams 

A general note regarding all the notification tables defined for each MOC below: Each MOC may potentially send the 
notifications listed in the notification table for the MOC. The notifications with qualifier (M) shall be supported by the 
MOC, and the notifications with qualifier (O) may be supported by the MOC. 

For example: If Notification notifyObjectCreation defined in Basic CM IRP has the qualifier (M), then if a MOC is 
defined such that it emits such a notification, this notification shall be emitted when appropriate (i.e. when a new object 
is created). If Notification notifyChangedAlarm has the qualifier (O) in Alarm IRP (see 3GPPTS 32.111-2 [11]), then if 
a MOC is defined such that it emits such a notification, this notification may or may not be emitted when appropriate. 
Further, if a notification in the qualifier column (of the MOC notification tables) has a reference to another 
specification, it means that the qualifier for the notification is specified in the referred specification. 

6.4.1.1 Inheritance hierarchy- 

Figure 8 shows the inheritance hierarchy for the UMTS NRM. Only new MOCs compared to subclause 6.3, and MOCs 
inherited from the generic model, are shown here. 
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MscFunction 
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VlrFunction 
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GmscFunction 





Figure 8: UMTS NRM Inheritance Hierarchy 

6.4.1 .2 Containment/Naming and Association diagrams 

Figures 9 and 10 show the containment/naming hierarchy and the associations of the UMTS NRM defined by this IRP. 

NOTE: The Managed Object containment/naming relationships are in the diagram(s) below indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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UtranCell 



NOTE 1: G3ManagedElement may be contained in either a G3SubNetwork or an MeContext instance, or have no parent 

instance at all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 3: The containment of MOCs NotificationlRP, AlarmIRP and BasicCmIRP under IRP Agent, which is shown in the 

generic model in subclause 6.3, is valid for this model as well. 

Figure 9: UMTS NRM Containment/Naming and Association diagram, Network-UTRAN view 



Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.106-8 [13] that 
expresses its containment hierarchy. As an example, the DN of a Managed Object representing a cell could have a 
format like: 

g3SubNetwork=Sweden, meContext=MEC-Gbg-l, g3ManagedElement=RNC-Gbg-l, rncFunction=RF-l, utranCell=Gbg- 
1. 
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G3ManagedElement 

(from Generic Model) 



MscFunction 0..1 



HlrFunction 0-1 



VlrFunction 0..1 



AucFunction 



0..1 



EirFunction 0..1 




0..1 SmslwmscFunction 



0..1 SmsGmscFunction 



0..1 



SgsnFunction 



0-1 GgsnFunction 



0.1 BgFunction 



GmscFunction 



NOTE: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 
creation and deletion scenarios. 

Figure 10: UMTS NRM Containment/Naming and Association diagram, CN view 

6.4.2 UMTS specific Managed Object Class (MOC) definitions 

6.4.2.1 MOC RncFunction 

This Managed Object Class represents RNC functionality. For more information about the RNC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 22: Attributes of RncFunction 



Name 


Qualifier 


Description 


rncFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance within 
the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 
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Table 23: Notifications of RncFunction 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yAt tribute ValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.2 



MOC NodeBFunction 



This Managed Object Class represents NodeB functionality. For more information about the NodeB, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 24: Attributes of NodeBFunction 



Name 


Qualifier 


Description 


nodeBFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely 
identifies the object instance within the scope of its containing 
(parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from ManagedFunction. 


nodeBFunction-IubLink 


READ-ONLY, M 


The value of this attribute shall be the DN of the related lubLink 
instance. This is a reference attribute modelling the role (of the 
association ConnectedTo) that this NodeBFunction is connected to 
0-1 lubLink. 



Table 25: Notifications of NodeBFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


M, See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1 ]) 




notifyAttribute ValueChange 


O 




notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 


O 




notifyObjectDeletion 


O 





6.4.2.3 



MOC UtranCell 



This Managed Object Class represents a radio cell controlled by the RNC. For more information about radio cells, see 
3GPPTS 23.002 [15]. 

It inherits from ManagedFunction. 
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Table 26: Attributes of UtranCell 



Name 


Qualifier 


Description 


utranCellld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely identifies 
the object instance within the scope of its containing (parent) object 
instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from ManagedFunction. 


utranCell-IubLink 


READ-ONLY, M 


The value of this attribute shall be the DN of the related lubLink 
instance. This is a reference attribute modelling the role (of the 
association AssociatedWith) that this UtranCell is associated with 0- 
1 lubLink. 



Table 27: Notifications of UtranCell 



Name Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yAt tribute ValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.4 



MOC lubLink 



The 'Iub link' managed object is the logical link to a NodeB as seen from the RNC. For more information about the 
RNC, see 3GPP TS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 28: Attributes of lubLink 



Name 


Qualifier 


Description 


iubLinkld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from ManagedFunction. 


iubLink-UtranCell 


READ-ONLY, M 


The value of this attribute shall be a list of the DN(s) of the related 
UtranCell instance(s). This is a reference attribute modelling the role (of 
the association AssociatedWith) that this lubLink is associated with 0-N 
UtranCells. 


iubLink-NodeBFunction 


READ-ONLY, M 


The value of this attribute shall be the DN of the related NodeBFunction 
instance. This is a reference attribute modelling the role (of the 
association ConnectedTo) that this lubLink is connected to 0-1 
NodeBFunction. 



Table 29: Notifications of lubLink 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yAt tribute ValueChange 


O 




notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 
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6.4.2.5 



MOC MscFunctioi 



This Managed Object Class represents MSC functionality. For more information about the MSC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 30: Attributes of MscFunction 



Name 


Qualifier 


Description 


mscFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance within 
the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 31 : Notifications of MscFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 


O 




notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 


O 




notifyObjectDeletion 


O 





6.4.2.6 



MOC HlrFunctioi 



This Managed Object Class represents HLR functionality. For more information about the HLR, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 32: Attributes of HlrFunction 



Name 


Qualifier 


Description 


hlrFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 33: Notifications of HlrFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 


O 




notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyObjectCreation 


O 




notifyObjectDeletion 


O 





6.4.2.7 



MOC VlrFunctioi 



This Managed Object Class represents VLR functionality. For more information about the VLR, see 3GPP TS 23.002 
[15]. 
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It inherits from ManagedFunction. 



Table 34: Attributes of virFunction 



Name 


Qualifier 


Description 


vlrFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 35: Notifications of virFunction 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yAt tribute ValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.8 



MOC AucFunction 



This Managed Object Class represents AUC functionality. For more information about the AUC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 36: Attributes of AucFunction 



Name 


Qualifier 


Description 


aucFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 37: Notifications of AucFunction 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yAt tribut e ValueChange 


O 




notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.9 



MOC EirFunction 



This Managed Object Class represents EIR functionality. For more information about the EIR, see 3GPP TS 23.002 
[15]. 

It inherits from ManagedFunction. 
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Table 38: Attributes of EirFunction 



Name 


Qualifier 


Description 


eirFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 39: Notifications of EirFunction 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.10 



MOC SmsIwmscFunction 



This Managed Object Class represents SMS-IWMSC functionality. For more information about the SMS-IWMSC, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 40: Attributes Of SmsIwmscFunction 



Name 


Qualifier 


Description 


SmsIwmscFunction Id 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 41 : Notifications Of SmsIwmscFunction 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yAttributeValueChange 


O 




notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.11 



MOC SmsGmscFunction 



This Managed Object Class represents SMS-GMSC functionality. For more information about the SMS-GMSC, see 
3GPPTS 23.002 [15]. 

It inherits from ManagedFunction. 
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Table 42: Attributes of SmsGmscFunction 



Name 


Qualifier 


Description 


SmsGmscFunction Id 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 43: Notifications Of SmsGmscFunction 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.12 



MOC GmscFunction 



This Managed Object Class represents GMSC functionality. For more information about the GMSC, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 44: Attributes Of GmscFunction 



Name 


Qualifier 


Description 


gmscFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 45: Notifications of GmscFunction 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yAttributeValueChange 


O 




notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.13 



MOC SgsnFunction 



This managed object class represents SGSN functionality. For more information about the SGSN, see 3GPP TS 23.002 
[15]. 

It inherits from ManagedFunction. 
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Table 46: Attributes of SgsnFunction 



Name 


Qualifier 


Description 


SgsnFunction Id 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 47: Notifications of SgsnFunction 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.14 MOC GgsnFunction 

This Managed Object Class represents GGSN functionality. For more information about the GGSN, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 48: Attributes Of GgsnFunction 



Name 


Qualifier 


Description 


ggsnFunotionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 49: Notifications of GgsnFunction 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yAttributeValueChange 


O 




notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.2.15 MOC BgFunction 

This Managed Object Class represents BG functionality. For more information about the BG, see 3GPP TS 23.002 [15]. 

It inherits from ManagedFunction. 
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Table 50: Attributes of BgFunction 



Name 


Qualifier 


Description 


bgFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 51 : Notifications of BgFunction 



Name 


Qualifier 


Notes 


not if yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yAttributeValueChange 


O 




not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not if yOb ject Creation 


O 




notif yOb ject Deletion 


O 





6.4.3 Associations 



6.4.3.1 



Association ConnectedTo (M) 



This bi-directional association models the relationship between the IubLink and NodeB (through the NodeBFunction). 
It has two roles, named IubLink-NodeBFunction and NodeBFunction- IubLink. These two roles model each MOC's 
association with the other MOC. Each role is in the MOC definition mapped to a reference attribute with the same 
name. 



6.4.3.2 



Association Associateciwith (M) 



This bi-directional association models the relationship between the IubLink and UtranCell. It has two roles, named 
IubLink-UtranCell and UtranCell-IubLink. These two roles model each MOC's association with the other MOC. Each 
role is in the MOC definition mapped to a reference attribute with the same name. 
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Annex A (informative): 

Supported UMTS network configurations 

Figure A.l depicts four typical network configurations, which are supported by the UMTS NRM over the Itf-N. 
However, this does not preclude support for other configurations. 




Itf-N 



Config. 1 



Config. 2 



Config. 3 



Config. 4 



Figure A.1 : Typical network configurations supported by the R99 UMTS NRM 

Table A. 1 shows the possible number of instances in R99 for each network configuration (counted from left to right in 
figure A.l.): 
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Table A.1 : Number of instances for each R99 example configuration in figure A.1 



MOC 


Config. 1 


Config. 2 


Config. 3 


Config. 4 


G3SubNetwork 


1 


1 


1 


0..1 


ManagementNode 


1 


1 








G3ManagedElement 


1..N 


1..N 


1..N 


1 


MeContext 


0..M 


0..M 


0..M 


0..1 


RncFunction 


0..P 


0..P 


0..1 


0..1 


NodeBFunction 


0..Q 


0..Q 


0..(N-1) 


0..1 


lubLink 


0..Q 


0..Q 


0..(N-1) 





UtranCell 


0..R 


0..R 


0..R 


0..R 


IRPAgent 


1 


1 


1 


1 


Notification I RP 


1 


1 


1 


1 


AlarmIRP 


0..1 


0..1 


0..1 


0..1 


BasicCmIRP 


0..1 


0..1 


0..1 


0..1 
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Annex B (normative): 

Event Types and Extended Event Types 

This annex lists and explains Event Types and Extended Event Types used by Basic CM IRP and then lists the Event 
Types and Extended Event Types valid for each notification in this IRP. 

Event Type is carried by a parameter called event Type defined in Notification IRP IS (3GPP TS 32.106-2 [3]). 

Extended Event Type is carried by a parameter called extendedEventType defined in Notification IRP IS (3GPP 
TS 32.106-2 [3]). 

Encoding of event Type and extendedEventType is Solution Set dependent. For example, the value of 
event Type may be encoded as an Object Identifier in the CMIP SS and as a numeric string in the CORBA SS. 

The tables below may be extended in the future. 

Table B.1 : Event Types 



Event Types 


Explanation 


Object creation 


A notification of this type indicates that a new managed object instance has been created 
(as defined in ITU-T X.721 [8] and ITU-T X.730 [9]). 


Object deletion 


A notification of this type indicates that a managed object instance has been deleted (as 
defined in ITU-T X.721 [8] and ITU-T X.730 [9]). 


Attribute value change 


A notification of this type indicates that the value(s) of one or more attributes have 
changed (as defined in ITU-T X.721 [8] and ITU-T X.730 [9]). 



Table B.2: Extended Event Types 



Extended Event Types 


Explanation 




In this release of the present specification, no Extended Event Types are used. Thus, this 
mandatory parameter from [3] is set to NULL in all notifications defined in this 
specification. 



Table B.3: Event types and Extended Event Types applicable to each Notification 



Notification 


Event Type 


Extended Event type 


not ifyObject Creation 


Object creation 


NULL 


not ifyOb ject Deletion 


Object deletion 


NULL 


not if yAttributeValueChange 


Attribute value change 


NULL 
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Annex C (informative): 
Change history 



Change history 
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CR 
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2.0.0 


3.0.0 
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SP-010029 


001 




UMTS Network Resource Model alignment with TSG RAN 
specifications 


3.0.0 


3.1.0 


Mar 2001 


S_11 
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002 




Correction of notifyObjectDeletion and notifyObjectCreation behaviour 
description 


3.0.0 


3.1.0 
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SP-010284 


003 




Correction of R99 filter definition which is inconsistent with the 
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Correction of UTRAN attributes 
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